Systems and methods for automatic product usage model training and prediction

ABSTRACT

Disclosed are methods, systems, and non-transitory computer-readable medium for executing neural network training for dynamically predicting apparel wearability. For example, a method may include generating a training data set comprising one or more historical data attributes of previously shipped apparel, training a neural network based on the training data set to configure one or more trained models to output a metric for any pair of a unique user identifier and a unique apparel identifier, storing one or more trained model objects, collecting prediction data comprising at least one prediction pair including a unique user identifier and a unique apparel identifier, predicting one or more predictive wearability metrics indicative of propensity to wear, dynamically generating one or more match pairs, and determining a match wearability metric for each of the one or more match pairs based on the predicted one or more predictive wearability metrics.

TECHNICAL FIELD

Various embodiments of the present disclosure generally relate todynamically predicting apparel wearability using machine learning andpredictive modeling, and more particularly, to executing uniquelytrained neural network model objects to dynamically predict apparelwearability using real-time transaction data.

BACKGROUND

For subscription-based services, a key driver for retaining subscribersand enhancing user activities is ensuring that the subscribed servicesare actually being used to a desired extent. For example, a subscriberof a service is not likely to consider subscription costs to beworthwhile if it becomes apparent to the subscriber that he or she hasnot been actually using the service to a sufficient extent.Alternatively, a subscriber may remain loyal to the service provider, orbecome even more actively involved in the subscription activities, ifthe subscriber is satisfied with the amount of actual use. Thus, it maybe highly desirable for subscription-based service providers to makerecommendations that increase the likelihood of actual use of theservice by its subscribers, and to achieve such an increase oflikelihood for as many users as possible despite their differences inindividual tastes or preferences.

The background description provided herein is for the purpose ofgenerally presenting the context of the disclosure. Unless otherwiseindicated herein, the materials described in this section are not priorart to the claims in this application and are not admitted to be priorart, or suggestions of the prior art, by inclusion in this section.

SUMMARY OF THE DISCLOSURE

According to certain aspects of the disclosure, systems and methods aredisclosed to execute neural network training for dynamically predictingapparel wearability.

In one embodiment, a computer-implemented method is disclosed forexecuting neural network training for dynamically predicting apparelwearability. The computer-implemented method may comprise: generating,by one or more processors, a training data set comprising one or morehistorical data attributes of previously shipped apparel, each of thehistorical data attributes being linked to a unique user identifier anda unique apparel identifier; training, by the one or more processors, aneural network based on the training data set to configure one or moretrained models to output a metric for any pair of a unique useridentifier and a unique apparel identifier; storing, by the one or moreprocessors, the one or more trained models as one or more trained modelobjects; collecting, by the one or more processors, prediction datacomprising at least one prediction pair including a unique useridentifier and a unique apparel identifier, each prediction paircorresponding to a closeted apparel, a purchased apparel, or a returnedapparel; predicting, by the one or more processors, one or morepredictive wearability metrics indicative of propensity to wear, byexecuting the stored one or more trained model objects with theprediction data, wherein the one or more predictive wearability metricsare one or more metrics output by the executed one or more trained modelobjects; dynamically generating, by the one or more processors, one ormore match pairs, each match pair including a unique user identifier anda unique apparel identifier; and determining, by the one or moreprocessors, a match wearability metric for each of the one or more matchpairs based on the predicted one or more predictive wearability metrics.

In accordance with another embodiment, a computer system is disclosedfor executing neural network training for dynamically predicting apparelwearability. The computer system may comprise: a memory havingprocessor-readable instructions stored therein; and at least oneprocessor configured to access the memory and execute theprocessor-readable instructions, which when executed by the processorconfigures the processor to perform a plurality of functions, includingfunctions for: generating a training data set comprising one or morehistorical data attributes of previously shipped apparel, each of thehistorical data attributes being linked to a unique user identifier anda unique apparel identifier; training a neural network based on thetraining data set to configure one or more trained models to output ametric for any pair of a unique user identifier and a unique apparelidentifier; storing the one or more trained models as one or moretrained model objects; collecting prediction data comprising at leastone prediction pair including a unique user identifier and a uniqueapparel identifier, each prediction pair corresponding to a closetedapparel, a purchased apparel, or a returned apparel; predicting one ormore predictive wearability metrics indicative of propensity to wear, byexecuting the stored one or more trained model objects with theprediction data, wherein the one or more predictive wearability metricsare one or more metrics output by the executed one or more trained modelobjects; dynamically generating one or more match pairs, each match pairincluding a unique user identifier and a unique apparel identifier; anddetermining a match wearability metric for each of the one or more matchpairs based on the predicted one or more predictive wearability metrics.

In accordance with another embodiment, a non-transitorycomputer-readable medium containing instructions is disclosed forexecuting neural network training for dynamically predicting apparelwearability. The non-transitory computer-readable medium may compriseinstructions for: generating a training data set comprising one or morehistorical data attributes of previously shipped apparel, each of thehistorical data attributes being linked to a unique user identifier anda unique apparel identifier; training a neural network based on thetraining data set to configure one or more trained models to output ametric for any pair of a unique user identifier and a unique apparelidentifier; storing the one or more trained models as one or moretrained model objects; collecting prediction data comprising at leastone prediction pair including a unique user identifier and a uniqueapparel identifier, each prediction pair corresponding to a closetedapparel, a purchased apparel, or a returned apparel; predicting one ormore predictive wearability metrics indicative of propensity to wear, byexecuting the stored one or more trained model objects with theprediction data, wherein the one or more predictive wearability metricsare one or more metrics output by the executed one or more trained modelobjects; dynamically generating one or more match pairs, each match pairincluding a unique user identifier and a unique apparel identifier; anddetermining a match wearability metric for each of the one or more matchpairs based on the predicted one or more predictive wearability metrics.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate various exemplary embodiments andtogether with the description, serve to explain the principles of thedisclosed embodiments.

FIG. 1 depicts an example environment in which methods, systems, andother aspects of the present disclosure may be implemented.

FIG. 2 depicts a block diagram schematically showing a systemarchitecture and data flow in an exemplary implementation of thewearability setup subsystem, according to one or more embodiments.

FIG. 3 depicts an exemplary method for transforming raw data attributeswith advanced features at the wearability setup subsystem, according toone or more embodiments.

FIG. 4 depicts an exemplary method for building wearability model at thewearability setup subsystem, according to one or more embodiments.

FIG. 5A depicts an exemplary method for processing prediction data atthe wearability setup subsystem, according to one or more embodiments.

FIG. 5B depicts an exemplary method for processing prediction data atthe wearability setup subsystem, according to one or more alternativeembodiments.

FIG. 6 depicts an exemplary method for generating predictive wearabilitymetrics using trained model objects, according to one or moreembodiments.

FIG. 7 depicts an exemplary method for generating predictive wearabilitymetrics using trained model objects, according to one or morealternative embodiments.

FIG. 8 depicts a flowchart of an exemplary method for executing neuralnetwork training for dynamically predicting apparel wearability,according to one or more embodiments.

FIG. 9 depicts an exemplary computer device or system, in whichembodiments of the present disclosure, or portions thereof, may beimplemented.

DETAILED DESCRIPTION OF EMBODIMENTS

The following embodiments describe systems and methods for executingneural network training in order to dynamically predict apparelwearability. As noted above, there exists a need for service providers(e.g., subscription-based service providers) to increase the likelihoodof actual use of the service by its users, and to achieve such anincrease of likelihood for as many users as possible despite theirdifferences in individual tastes or preferences. A service platform withsuch an objective may include, for example an electronic platform thatenable users to subscribe to, purchase, or rent apparel, operating underkey considerations such as, for example, determining whether eachsubscriber actually wears the rented apparel in a particular rentalcycle. The value of the service may improve greatly if the providerintelligently allocates or recommends apparel with higher probabilitiesof being worn by the user.

While the exemplary system architecture as described in the presentdisclosure relates to an electronic transactions for subscribing to,purchasing, or renting apparel (e.g., clothing-as-a-service (CaaS) orTry-Then-Buy (TTB) service), implementations disclosed herein mayeffectively serve any other subscription, product purchase, or onlinetransaction service such as, for example, subscribing to or makingpurchases in a software service, cleaning service, delivery service,maintenance service, rental product, rental vehicles, etc., withoutdeparting from the scope of the disclosure. For example, thecharacteristic of being wearable or having a measure of high wearability(e.g., having propensity to wear apparel) may correspond to acharacteristic of being usable in contexts outside of apparel (e.g.,having propensity to use a subscribed rental product or service).

In accordance with the present disclosure, allocating or recommendingapparel and/or a virtual closet of apparel with a higher percentage ofbeing worn by the subscriber may be achieved by uniquely configuredmachine learning and predictive modeling. Given the vast amount of dataattributes that may be collected from historical transactions, data setsindicative of each user's relationship with certain apparel (e.g., abinary flag of whether a shipped garment was actually worn by a user)may be formed and/or retrieved. Additionally, a computing system maytransform such data sets to a training data set, and run neural networkmodel training using the training data set. Within this process,specifically customized training of neural networks, combined with theirpractical application of constantly predicting wearability metrics andproviding a user with highly wearable apparel, produces unconventionaland unique automations which necessarily achieve technologicalimprovements through the particular automation processes described morein detail below. Consequently, the unconventional and unique aspects ofthese automation processes represent a sharp contrast to merelyproviding a well-known or routine environment for performing a manual ormental task.

The subject matter of the present description will now be described morefully hereinafter with reference to the accompanying drawings, whichform a part thereof, and which show, by way of illustration, specificexemplary embodiments. An embodiment or implementation described hereinas “exemplary” is not to be construed as preferred or advantageous, forexample, over other embodiments or implementations; rather, it isintended to reflect or indicate that the embodiment(s) is/are “example”embodiment(s). Subject matter can be embodied in a variety of differentforms and, therefore, covered or claimed subject matter is intended tobe construed as not being limited to any exemplary embodiments set forthherein; exemplary embodiments are provided merely to be illustrative.Likewise, a reasonably broad scope for claimed or covered subject matteris intended. Among other things, for example, subject matter may beembodied as methods, devices, components, or systems. Accordingly,embodiments may, for example, take the form of hardware, software,firmware, or any combination thereof (other than software per se). Thefollowing detailed description is, therefore, not intended to be takenin a limiting sense.

Throughout the specification and claims, terms may have nuanced meaningssuggested or implied in context beyond an explicitly stated meaning.Likewise, the phrase “in one embodiment” as used herein does notnecessarily refer to the same embodiment and the phrase “in anotherembodiment” as used herein does not necessarily refer to a differentembodiment. It is intended, for example, that claimed subject matterinclude combinations of exemplary embodiments in whole or in part.

The terminology used below may be interpreted in its broadest reasonablemanner, even though it is being used in conjunction with a detaileddescription of certain specific examples of the present disclosure.Indeed, certain terms may even be emphasized below; however, anyterminology intended to be interpreted in any restricted manner will beovertly and specifically defined as such in this Detailed Descriptionsection. Both the foregoing general description and the followingdetailed description are exemplary and explanatory only and are notrestrictive of the features, as claimed.

As used in the present disclosure, the term “CaaS” (i.e.,clothing-as-a-service) may collectively refer to computer-implementedservices and functions associated with subscription, purchase, and/orrental services for users (e.g., periodic subscription for receivingapparel, apparel rental or purchase order, distribution, returnprocessing, TTB services, account management, marketing, customerservice, warehouse operations, etc.). As used in the present disclosure,the term “apparel” may refer to any article of clothing, apparel,jewelry, hat, accessories, or other product which may be worn by a user.

As used in the present disclosure, the term “wearability” may refer to apropensity or a probability of a user actually wearing a given garment,and the term “wearability metric” may be a metric indicating a level ofwearability. As used in the present disclosure, the term “closeting” or“to closet” may refer to a computer-implemented operation of placing oneor more garments into a virtual closet (e.g., a cart, a repository, orany type of space which may be virtually associated with a particularset of one or more garments for a future transaction). Additionally,“matching” may refer to a computer-implemented operation of determininga set of one or more matching garments and/or determining wearabilitymetrics for given garments, and “allocating” may refer to acomputer-implemented operation of determining the garments that shouldbe assigned and shipped to one or more particular users.

In this disclosure, the term “based on” means “based at least in parton.” The singular forms “a,” “an,” and “the” include plural referentsunless the context dictates otherwise. The term “exemplary” is used inthe sense of “example” rather than “ideal.” The term “or” is meant to beinclusive and means either, any, several, or all of the listed items.The terms “comprises,” “comprising,” “includes,” “including,” or othervariations thereof, are intended to cover a non-exclusive inclusion suchthat a process, method, or product that comprises a list of elementsdoes not necessarily include only those elements, but may include otherelements not expressly listed or inherent to such a process, method,article, or apparatus. Relative terms, such as, “substantially” and“generally,” are used to indicate a possible variation of ±10% of astated or understood value.

Referring now to the appended drawings, FIG. 1 shows an exampleenvironment 100, according to one or more embodiments of the presentdisclosure. As shown, the example environment 100 may include one ormore user devices 110, a network 112, product online transactionprocessing (product OLTP) component 114, a publisher 136, warehousemanagement system (WMS) 138, and wearability modeling and matchingsystem 140.

Users of the example environment 100 may use one or more user devices110 (e.g., a computing device, a mobile device, or the like) to accessand/or apply the results generated from the wearability modeling andmatching system 140. The one or more user devices may be incommunication with the product OLTP component 114, the WMS 138, and/orother user devices among the user devices 110, using a network 112.Further, the user devices 110 may allow a user to display a web browser,an application, or any other user interface for accessing informationgenerated by product OLTP component 114, warehouse management system138, and/or other user devices among the user devices 110. For example,a device among the one or more of the user devices 110 may load anapplication with graphical user interface (GUI), and the application maydisplay on the GUI one or more apparel recommendations for closeting bythe user.

The wearability modeling and matching system 140 may provide users withvarious features necessarily providing technical improvements overplatforms which merely provide users with selection choices withoutwearability analysis functions. In some implementations, the wearabilitymodeling and matching system 140, along with product OLTP component 114and/or WMS 138, may provide a user with computer-implemented user-facingrecommendations of apparel. These computer-implemented recommendations,for example, may uniquely take into account (i) which apparel(s) theparticular user is likely to wear, (ii) apparel(s) similar to otherapparel(s) which the particular user is likely to wear, (iii) apparel(s)with high wearability to other users who are similar to the particularuser, and/or (iv) apparel(s) with high wearability to other users whohave had similar experiences with the particular user. In making suchrecommendations to the user interface, the wearability modeling andmatching system 140, along with product OLTP component 114 and/or WMS138, may use wearability metrics (e.g., predictive wearability metricsand/or match wearability metrics as described in detail below) as keyconsiderations. For example, the user interface at the user devices maydisplay apparel that ranks above a preset threshold number, in a rankedlist of predictive wearability metrics and/or match wearability metrics.

Additionally, or alternatively, the wearability modeling and matchingsystem 140, along with product OLTP component 114 and/or WMS 138, mayuse wearability metrics (e.g., predictive wearability metrics and/ormatch wearability metrics as described in detail below) as keyconsiderations for one or more closet curation features. For example,the environment 100 may assist user devices 110 (e.g., by providingrecommendations for notifications) at purging or replacing apparel withlow wearability based on one or more reasons such as size, seasonality,styles, fabric, and/or other advanced attributes. In theseimplementations, the wearability modeling and matching system 140, alongwith product OLTP component 114 and/or WMS 138, may select apparel withlow wearability metrics (e.g., predictive wearability metrics and/ormatch wearability metrics as described in detail below) below a presetthreshold value.

The product OLTP component 114 may be one or more computer-implementeddata processing and storage systems configured to process onlinetransactions from user devices 110. The product OLTP component 114 mayprocess, for example, order entries, sales transactions, returnprocessing, replenishment support/processing, and financialtransactions. Further, the product OLTP component 114 may be incommunication with at least the replenishment system 122, the publisher136, and matching setup engine 126 with message bus or channels toexchange data with other connected systems. The publisher 136 may, forexample, receive information from the product OLTP component 114 andcommunicate the received information to the WMS 138. The product OLTPcomponent 114 may include, or be connected to, one or more databaseswith tables or any other data structures included therein. The one ormore databases included in or connected to the product OLTP component114 may be configured to receive and respond to queries for dataassociated with transactions. Additionally, or alternatively, the one ormore databases in the product OLTP component 114 may be configured totransmit data at regularly scheduled intervals, transmit data via anasynchronous scheduling, and/or respond to authorized requestsassociated with reading, writing, and/or retrieving the data storedtherein.

The wearability modeling and matching system 140 may provide anarchitecture for a plurality of sub-processes associated with predictivemodeling and wearability matching/allocations, including generatinganalytics, wearability training, wearability prediction, and wearabilitymatching. As supporting architecture for the sub-processes, thewearability modeling and matching system 140 may comprise variouscomponents, such as a BI (business intelligence) component 116, awearability setup subsystem 118, a metrics database 120, a replenishmentsystem 122, a match database 134, RID information repository 124, amatching setup engine 126, a match setup file repository 128, a matchingengine 130, and a match result file repository 132.

The BI component 116 may store and/or provide historical informationstored in a data warehouse, as well as new data gathered from othersource systems as they are generated, such as, for example, bothhistorical analytics and real-time predictions. For example, the datastored and output by BI component 116 may comprise raw attributes from adata warehouse, historical shipping and RN (return notification) data,and historical closet data, as well as dynamic data feed from activecloset, as described in more detail below with respect to FIG. 2. BIcomponent 116 may serve as the sole source of data feed for wearabilitysetup subsystem 118. Additionally, or alternatively, the wearabilitysetup subsystem 118 may be in communication with, and receive data, fromproduct OLTP component 114.

The wearability setup subsystem 118 may be in communication with BIcomponent 116 and/or the product OLTP component 114, and may comprise aplurality of modules which perform wearability data preparation,wearability training, and wearability prediction. The individual moduleswhich may perform these functions are described in detail below withrespect to FIG. 2. The wearability setup subsystem 118 may receive inputdata from BI component 116, which may comprise, for example, rawattributes, historical shipping and return notification data, historicalcloset data, and active closet data. The receiving or streaming or inputdata from BI component 116 may run periodically, asynchronously, or viapush and/or pull operations.

The wearability setup subsystem 118 may be in communication with ametrics database 120. The metrics database 120 may be comprise datamanagement components and/or databases such as, for example,Elasticsearch, Hbase, or any other data search/storage componentscapable of indexing, retrieving, and/or searching documents, orfunctioning as key-value-pair stores. The wearability setup subsystem118 may transmit output data to the metrics database 120. The outputdata may be, for example, one or more predictive wearability metricsindicative of propensity to wear one or more garments. Such one or morepredictive wearability metrics may, for example, each correspond to aprediction pair including a unique user identifier (e.g., UUID) and aunique apparel identifier (e.g., a stock keeping unit or “SKU”). Thespecific functions by which the wearability setup subsystem 118 producesthe output data based on the input data is described in further detailwith respect to FIG. 2 below.

The replenishment system 122 may be in communication with the productOLTP component 114, and may receive input data from the product OLTPcomponent 114 periodically, asynchronously, or via push and/or pulloperations (e.g., dynamic feed into the replenishment system 122). Theinput data may be, for example, return notification (RN) attributes of auser's RN, as well as any other data attributes associated with RNattributes. Based on the input data, the replenishment system 122 maygenerate replenishment identifiers (RIDs) for a user, along with anyother data attributes associated with each RID. An RID may be, forexample, an identifier generated by the replenishment system 122 inresponse to a user's RN and/or a detection that a user has an open slotand is eligible for next box and shipping. Additionally, oralternatively, the wearability setup subsystem 118 may generate RIDs ina modeling data processing module 216, as described in further detailwith respect to FIG. 2 below. The replenishment system 122 may transmitRIDs, along with any other data attributes associated with each RID, toa match database 134.

The match database 134 may be in communication with the replenishmentsystem 122. The match database 134 may comprise one or moresubcomponents such as, for example, RID information repository 124, amatch setup file repository 128, and a match result file repository 132.The match database 134 may receive the RIDs (e.g., along with any otherdata attributes associated with each RID) and store the received data toRID information repository 124.

The matching setup engine 126 may be in communication with the metricsdatabase 120, the match database 134, the RID information repository124, match result file repository 132, and the product OLTP component114. The matching setup engine 126 may be run in cycles, such as inperiodic cycles (e.g., every hour), asynchronously, or via push and/orpull operations based on events such as generation of an RID. At eachcycle, the matching setup engine 126 may receive one or more RIDsdynamically generated at the RID information repository 124.Additionally, or alternatively, the matching setup engine 126 mayreceive generated RIDs from the metrics database 120. For the receivedRIDs, the matching setup engine 126 may retrieve all data attributes ormetadata related to those RIDs, such as unique user identifiers (e.g.,UUIDs), unique apparel identifiers (e.g., SKU information), and/or anyother data attributes associated with the unique user identifiers and/orapparel identifiers, from product OLTP component 114. In someimplementations, the matching setup engine 126 may also receive dataattributes associated with active closets or closeted apparel, from theproduct OLTP component 114, in order to generate match pairs based onactive closet data.

The matching setup engine 238 may then dynamically generate match pairs,each match pair including a unique user identifier (e.g., UUID) and aunique apparel identifier (e.g., SKU) retrieved from the product OLTPcomponent 114. The matching setup engine 238 may then retrieve acorresponding match wearability metric from the metrics database 120,from the predictive wearability metrics stored at the metrics database120. For example, for each match pair, the matching setup engine 126 maymake an online request to the metrics database 120, to retrieve thepredictive wearability metric which correspond to the match pair (e.g.,UUID-SKU), and store it as the match wearability metric for the matchpair, at the match setup file repository 128 in the match database 134.

In some implementations, the matching setup engine 238 may perform itsfunctions in separate and independent cycles from the functionsperformed by wearability setup subsystem 118. For example, thewearability setup subsystem 118 may perform its functions of preparingand building wearability model, processing prediction data, andgenerating predictive wearability metrics offline (e.g., as back-endoperation cycles which may be performed at different and independentschedules in comparison to the operation cycles performed by thematching setup engine 238) and store the output data in the metrics forad hoc online retrievals by the matching setup engine 238. Such animplementation may achieve reduced online execution times of producingwearability metrics, in comparison to implementation in whichwearability setup subsystem 118 and matching setup engine 238 performoperations together at each online request or each cycle iteration. Theimplementation of offline computations by wearability setup subsystem118 (e.g., computations performed independently from online activitiesof the matching setup engine 238) may result in latency of data requiredat the matching setup engine 238, such as missing match pairs. To remedysuch latency, if there exists a missing predictive wearability metricsfor match pairs at matching setup engine 238, the matching setup engine238 may generate an alert and/or fill the missing data with a defaultvalue (e.g., a neutral value such as 50%, or any other preset defaultvalue).

Alternatively, the wearability setup subsystem 118 and the matchingsetup engine 238 perform operations together in each cycle iteration,such that predictive wearability metrics are generated online forimmediate use by the matching setup engine 126 (e.g., without anylatency caused by independently performed storage operations, or withouta need for the metrics database 120). Such implementation of onlinemetrics computation may eliminate latency of data between thewearability setup subsystem 118 and the matching setup engine 238, andalso enable the online retrieval services to be used by other subsystems(e.g., subsystems within the environment 100, and/or subsystems incommunication with the environment 100). This implementation may resultin higher online execution times of producing wearability metrics, incomparison to the offline computation implementation described above.

The matching engine 130 is in communication with the match setup filerepository 128 and the match result file repository 132. The matchingengine 130 may run in cycles, such as in periodic cycles (e.g., everyhour), asynchronously, or via push and/or pull operations. The matchingengine 130 may run in the same, synchronous cycles as the matching setupengine 126. At every cycle, the matching engine 130 may receive inputdata from the match setup file repository 128, such as the stored matchwearability metrics for one or more match pairs. Based on the receiveddata, the matching engine may generate, for example, two result filesfor each match pair. A first result file may have the wearabilitymetrics associated with the match pair, such as, for example, expectedwearability probability, average wearability rate, priority successrate, missing keys at match-setup time, and number of matches-in-pickingwithout computed metrics. A second result file may have cost-functionresults for the matching optimization which may be calculated by, forexample, first calculating an adjusted score as adjustedscore=I(is_prioritized)*x*match wearability metric, and then calculatingthe cost for matching allocation as x-adjusted score. The result filesmay be then stored at the match result file repository 132.

The match result file repository 132 may be in communication with thematching engine 130 and the publisher 136. The publisher 136 may be incommunication with WMS 138. Both the publisher 136 and WMS 138 may be incommunication with the user devices 110 via the network 112. Thepublisher 136 may retrieve data attributes from the result files storedin the match result file repository 132, and output data from the resultfile (e.g., wearability metrics, average wearability rate, prioritysuccess rate, missing keys at match-setup time, and number ofmatches-in-picking without computed metrics) in a specifically preset ordefault publishing format. The output of the publisher 136, for example,may be retrieved directly by the user devices 110, or by the WMS 138.The WMS 138 may be connected to the user devices 110 via the network112. The WMS 138 may perform functions of, for example, storing and/ortransmit warehouse management data attributes derived or generated basedon the output of the publisher 136.

The number and arrangement of devices, networks, and components shown inFIG. 1 are provided as an example. In practice, there may be additionaldevices and/or components, fewer devices and/or components, differentdevices and/or components, or differently arranged devices and/orcomponents than those shown in FIG. 1. Furthermore, two or more devicesor components shown in FIG. 1 may be implemented within a single device,or a single device shown in FIG. 1 may be implemented as multiple,distributed devices. Additionally, or alternatively, a device orcomponent of environment 100 may perform one or more functions describedas being performed by another device or component of environment 100.

FIG. 2 depicts a block diagram schematically showing a systemarchitecture and data flow in an exemplary environment 200 of thewearability setup subsystem, according to one or more embodiments. Theexemplary environment 200 may have two processes which run respectivelyin two computing environments, such as a model training environment 201and a matching environment 202. The model training environment 201 maybe implemented using, for example, SQL and/or Python. The matchingenvironment 202 may be implemented using, for example, Java or any otherprogramming language capable of conditional matching algorithms. Asdescribed above with respect to FIG. 1, the model training environment201 may host an offline process of predictive wearability metricscomputations, which may not need to run in real-time to any operation ofthe matching environment 202, or be executed online together with anyonline process of the matching environment 202. Alternatively, the modeltraining environment 201 and the matching environment 202 may both runonline (e.g., both running a cycle in each online process), such thatpredictive wearability metrics are generated online for immediate usewithout any data latency.

The model training environment 201 may comprise a wearability setupsubsystem 203, which may execute a plurality of different modules (e.g.,a modeling data processing module 216, a wearability model buildingmodule 218, a prediction data processing module 222, and a predictivemetrics generating module 224). These modules may be softwareinstructions executed by one or more processors associated with thewearability setup subsystem 203. In some implementations, thewearability setup subsystem 203 may correspond to the wearability setupsubsystem 118 of FIG. 1.

The wearability setup subsystem 203 may receive various data attributesin order to build a training data set for neural network training, andto generate prediction data such as, e.g., [UUID, SKU] prediction pairseach combined with predictive wearability metrics. The data attributesreceived may be raw attributes 210, historical shipping and RNs 212,historical closet data 214, and active closet data 220, and the dataattributes may be received from BI component 116 and/or product OLTPcomponent 114.

The modeling data processing module 216 may prepare and process modelingdata, which are needed for the machine learning process of models thatproduce predictive wearability metrics. First, in input data, such asraw attributes 210, historical shipping and RNs 212, and historicalcloset data 214, may be received from BI component 116 and/or productOLTP component 114. In some implementations, the raw attributes 210 maybe gathered and placed into advanced analytics tables, as described infurther detail with respect to FIG. 3 below. Based on the advancedanalytics tables, raw attributes 210, historical shipping and RNs 212,and/or historical closet data 214, the modeling data processing module216 may join feature vectors for shipped pairs with RNs. For example,shipped pairs of garments may form a vector such as (UUID, SKU, shippeddate), and this vector may be joined with features having analytics(e.g., analytics from the advanced analytics tables, or any otheruser/SKU/apparel/closet level attributes retrieved from raw attributes210, historical shipping and RNs 212, and/or historical closet data214). As used herein, a feature may refer any analytics used in themodel training environment 201, and an analytic may refer to anyuser/SKU/apparel/closet level attribute.

Then, these joined vectors may be downloaded into one or more data files(e.g., one or more csv files, or any other one or more types of datafiles capable of storing joined vectors), and the criteria for suchdownloading may be limited by conditions if there are preset conditions.For example, there may be a condition that only apparel shipped in thepast x days (e.g., 90 days) may be loaded into the csv files. With thedata set from the one or more csv files, the modeling data processingmodule 216 may then clean the data set, based on further conditions. Forexample, the modeling data processing module 216 may detect a presetcondition that data associated with historical feedback from users maybe used only if the data has an RN count (e.g., number of RNs receivedregarding that apparel or that user) over 5, or any other presetthreshold value. In this example, any data with less than or equal tothe preset threshold value may be voided from the data set as part ofthe cleaning process.

After cleaning the data, the modeling data processing module 216 maythen transform the data set by running the data set into additionalfilters and conversions. For example, features having at least x % ofmissing data attributes (e.g., with x being a preset number such as 50)may be removed from the data set. In addition, categorical features maybe dummified. For example, attributes pertaining to a category ofapparel or users, rather than to an individual garment or user, may havearbitrary, inaccurate, or unfilled values when compared to attributespertaining to individual (UUID, SKU) pairs, and such values may bereplaced with dummy values. Additionally, missing features may beimputed by, for example, searching for the missing feature value fromother places (e.g., BI component 116, product OLTP component 114, or anyother database or internal storage accessible by wearability setupsubsystem 203), and/or filling the missing features with default, presetvalue. Additionally, the features may also be normalized, by realigningor adjusting values based on a preset factor, removing outliers, and/orstandardizing the values in any way in accordance with preset rules orconditions. In some implementations, the modeling data processing module216 may save the resulting training data set as modeling ETL (Extract,Transform, Load) objects in one or more target databases incommunication with wearability setup subsystem 203. The training dataset may become available (e.g., by transmission or storing at designatedfiles and locations) for the wearability model building module 218 touse in a neural network training process.

The wearability model building module 218 may perform the trainingprocess for producing models, using the training data set output fromthe modeling data processing module 216. As discussed above, thetraining process may be performed as an offline process, and as such,may run fewer, independent cycles (e.g., 1-3 times a day as opposed tohourly) compared to the matching operations of the matching environment202. In each cycle of training, a neural network may be trained based onthe training data set. As used herein, a neural network may be, forexample, a deep learning neural network that has more layers thantraditional neural network. The wearability model building module 218may train a neural network such that trained models may be configured tooutput a metric for any pair of a unique user identifier and a uniqueapparel identifier (e.g., a predictive wearability metric indicative ofpropensity to wear, which may be a predicted wearability score based ona predictive modeling from the training or a default score). Forexample, the output metric may be an average rate that a given garmentwas reported as worn (e.g., binary flag of worn vs. not worn inuser-provided RNs) by a given set of users (the user corresponding tothe UUID, or a set of users associated with that user based on userattributes). After a cycle of training a neural network, one or moretrained models resulting from the training may be stored as trainedmodel objects in one or more databases in communication with wearabilitysetup subsystem 203.

In some implementations, the wearability setup subsystem 203 may alsoevaluate the trained model objects, by executing or simulating thetrained model objects generated at the wearability model building module218, and assessing the objects. For example, the assessment may comprisepredicting wearability metrics for training pairs, and calculatingassessment metrics such as accuracy, AUC (Area Under the Curve),precision, recall, etc. The AUC may, for example, be used in aclassification analysis in order to determine which of the model objectsbest predicts classes.

The prediction data processing module 222 may collect and prepare datain order for the predictive metrics generating module 224 to generatepredictive wearability metrics. The prediction data processing module222 may collect data as close to real-time as possible. For example, ifa user just closeted a new garment and/or return notified (e.g., sent anRN for) a garment, the prediction data processing module 222 may capturedata attributes associated with all of those activities immediately,because obtaining or missing one data attribute for a user may have aneffect on the predictive wearability metrics produced by the predictivemetrics generating module 224. The active closet data may be receivedfrom BI component 116. Active data related to RNs may be received from,for example, the modeling data processing module 216. Additionally, theprediction data processing module 222 may not only capture new closetingor RN data relationships (e.g., UUID-SKU relationship), but also collectdata attributes related to the relationship (e.g., details regardingeach SKU on attribute levels), from the BI component 116, the modelingdata processing module 216, or any other databases in in communicationwith the environment 200.

Using the collected data, the prediction data processing module 222 mayprepare the prediction data for subsequent steps (e.g., steps performedby the predictive metrics generating module 224). First, the predictiondata processing module 222 may define the universe of the closeted pairsof unique user identifiers and unique apparel identifiers. Then it mayjoin advanced features (e.g., advanced analytics tables described withrespect to processing modeling data) for the closeted pairs. Thecloseted files may then be downloaded into one or more csv files. Withthe data set from the one or more csv files, the prediction dataprocessing module 222 may then clean the data set, based on furtherconditions. For example, prediction data processing module 222 maydetect a preset condition that data associated with historical feedbackfrom users may be used only if the data has an RN count (e.g., number ofRNs received regarding that apparel or that user) over 5, or any otherpreset threshold value. In this example, any data with less than orequal to the preset threshold value may be voided from the data set aspart of the cleaning process.

After cleaning the data, the prediction data processing module 222 maythen transform the data set by running the data set into additionalfilters and conversions. For example, model ETL objects (saved by themodeling data processing module 216) may be loaded. In addition,categorical features may be dummified. For example, attributespertaining to a category of apparel or users, rather than to anindividual garment or user, may have arbitrary, inaccurate, or unfilledvalues when compared to attributes pertaining to (UUID, SKU) pairs, andsuch values may be replaced with dummy values. Additionally, missingfeatures may be imputed by, for example, searching for the missingfeature value from other places (e.g., BI component 116, product OLTPcomponent 114, or any other database or internal storage accessible bywearability setup subsystem 203), and/or filling the missing featureswith default, preset value. Additionally, the features may also benormalized, by realigning or adjusting values based on a preset factor,removing outliers, and/or standardizing the values in any way inaccordance with preset rules or conditions. As a result of thesetransformations, the prediction data may be prepared and becomeavailable for the module for the predictive metrics generating module224.

The predictive metrics generating module 224 may then run prediction onthe prediction data, by predicting one or more predictive wearabilitymetrics indicative of propensity to wear. Such a prediction may occur byloading the stored one or more trained model objects, executing thetrained model objects with the prediction data, and generatingpredictive wearability metrics resulting from the execution of thetraining model objects. In some implementations, the predictive metricsgenerating module 224 may also predict metrics or scores for trainingpairs (e.g., for purposes of assessment or training associated with theprediction process). The predictive metrics generating module 224 maythen store the resulting predictive wearability metrics in metricsdatabase 120, as described above with respect to FIG. 1.

In the matching environment 202, match wearability metrics andcost-function outputs may be generated. Based on predictive wearabilitymetrics output from the predictive metrics generating module 224, aswell as real-time RIDs and real-time closet received from the productOLTP component 114 and/or the RID information repository 124, thematching environment 202 may dynamically generate result file 240 havingmatch wearability metrics and cost-function outputs. This process may beperformed by matching setup engine 236 and matching engine 238, whichhave been described in detail with respect to FIG. 1 above. For example,in some implementations, matching setup engine 236 may correspond to thematching setup engine 126 of FIG. 1, and the matching engine 238 maycorrespond to the matching engine 130 of FIG. 1.

The number and arrangement of devices, networks, and modules shown inFIG. 2 are provided as an example. In practice, there may be additionaldevices and/or modules, fewer devices and/or modules, different devicesand/or modules, or differently arranged devices and/or modules thanthose shown in FIG. 2. Furthermore, two or more devices or modules shownin FIG. 2 may be implemented within a single device, or a single deviceshown in FIG. 2 may be implemented as multiple, distributed devices.Additionally, or alternatively, a device or a module of environment 200may perform one or more functions described as being performed byanother device or module of environment 200.

FIG. 3 depicts an exemplary method 300 for transforming data attributeswith advanced features at the wearability setup subsystem 203. Asdescribed above with respect to FIG. 2, the modeling data processingmodule 216 may receive various input data, including raw attributes 210,historical shipping and RNs 212, and/or historical closet data 214 fromdata tables at BI component 116. The modeling data processing module 216may collect, analyze, and/or organize (e.g., via SQL queries) the inputdata 302 (Step 304) according to preset criteria, to generate and/orappend the advanced features 306. For example, the modeling dataprocessing module 216 may generate one or more patterns and/ordistributions as data among the advanced features 306, based on rawattributes 210, historical shipping and RNs 212, and/or historicalcloset data 214. The generated one of more patterns and/or distributionsmay be, for example, fit ratings of each garment (e.g., apparelcorresponding to each unique apparel identifier), output asdistributions in quartiles, and the distributions may include aplurality of distributions based on groups, such as users of differentgeographical locations, or apparel attributes (e.g., color, hemlinelength, etc.). The generated and/or appended advanced features may bestored, for example, at data tables at BI component 116 or any otherdatabase in communication with the environment 100, with writeprotection and access capability by wearability setup subsystem 203. Insome implementations, the advanced features may be used as the trainingdata set for the wearability model building module 218. An example ofthe advanced features is shown in Table 1.

TABLE 1 Historical Cumulative Data Historical shipped pairs (UUID, SKU,date - actual worn, fit rating, etc.) User cumulative RNs, as of a(UUID, date - % worn, average fit given hist, date rating, count, etc.)SKU cumulative RNs, (SKU, date - average fit as of a given date rating,count, etc.) Style + Color cumulative RNs, (garment, date - averageheart as of a given date rating, count, etc.) SKU cumulative product(SKU, date - avg product reviews, as of a given date reviews, count,etc.) User cumulative shipments, as (UUID, date - # shipped boxes, of agiven hist. Date # shipped SKUs, etc.) User canonical (user - last RNdate, size (c-size) average c-size with good + fitting, min c-size, maxc-size, etc.) Pair last feedback dates (UUID, SKU, shipped date - userlast RN date, SKU last RN date, etc.) Closet attributes (UUID, SKU,shipped date - is prioritized, closet date, etc.) SKU usage (SKU, date -average # usage for available snowflakes, etc.) Static Data Userattributes (user - tenant id, first shipped date, # at home, closetsize, plan size, etc.) SKU attributes (SKU - c-size, brand, producttype, retail price, gb purchase price, fabric, etc.) Skyle + (garment -hemline length, Color attributes neckline shape, etc.)

FIG. 4 depicts an exemplary method 400 for building wearability model atthe wearability setup subsystem 203. The wearability model buildingmodule 218 may receive advanced features 402 from the modeling dataprocessing module 216. (Step 404). Additionally, or alternatively, thewearability model building module 218 may download training data setgenerated by the modeling data processing module 216, from BI component116, a database in communication with the wearability setup subsystem203, and/or the modeling data processing module 216 (Step 404). Thewearability model building module 218 may then train a neural networkbased on the training data set to configure one or more trained modelsto output a metric for any pair of a unique user identifier and a uniqueapparel identifier (Step 408). The training may be implemented using,for example, Python, and the training may predict a model such that themodel predicts a metric for every pair. For example, the training may beconfigured such that missing numeric features are filled with the groupaverage, zero, or a preset value, and missing categorical features aretreated as a new category. Lastly, the one or more trained models may bestored as one or more trained model objects 410. In someimplementations, two types of model objects may be generated for eachtraining model, one for data pre-processing and one for scoring metrics.The trained model objects may be stored, for example, at a databasewithin wearability setup subsystem 203 and backed up at match database134.

FIG. 5A depicts an exemplary method 500A for processing prediction dataat the wearability setup subsystem 203. The prediction data processingmodule 222 may receive real-time data 502 and the advanced features 504.The advanced features may be received from the modeling data processingmodule 216. The real-time data 502 may be received, for example, fromthe BI component 116, the product OLTP component 114, and/or the matchdatabase 134. The real-time data 502 may include, for example, real-timeRID, active closet data, transaction data, subscription user feedbackdata, user data such as unique user identifiers, and/or apparel datasuch as unique apparel identifiers. Then the prediction data processingmodule 222 may generate prediction data 508 by collecting and organizingthe input data (e.g., real-time data 502 and advanced features 504) intoa preset format (e.g., UUID-SKU format) which may be used by thepredictive metrics generating module 224 (Step 506). In someimplementations, the prediction data may saved as one or more csv filesat a database in communication with the wearability setup subsystem 203.

FIG. 5B depicts an exemplary method 500B for processing prediction dataat the wearability setup subsystem 203, according to one or morealternative embodiment. The prediction data processing module 222 mayreceive real-time data and the advanced features 514. The real-time datamay include real-time RID/user data 512, real-time closet data 516, andreal-time inventory data 518, which may be received, for example, fromthe BI component 116, the product OLTP component 114, and/or the matchdatabase 134. The advanced features may be received from the modelingdata processing module 216. Then, the prediction data processing module222 generate matching candidates 522 (Step 520), by for example,applying a preset filter to the real-time data. The prediction dataprocessing module 222 may then join data tables from matching candidates522, and data from advanced features 514 (Step 524). For example,generating of matching candidates may be implemented using Python, andSteps 520 and 524 may run in periodic cycles (e.g., three times a day).The data set resulting from joining of the data tables may be saved asthe prediction data 526. In some implementations, the prediction datamay saved as one or more csv files at a database in communication withthe wearability setup subsystem 203. For example, the prediction data526 may be in preset format (e.g., UUID-SKU format) which may be used bythe predictive metrics generating module 224.

FIG. 6 depicts an exemplary method 600 for generating predictivewearability metrics using trained model objects, according to one ormore embodiments. The predictive metrics generating module 224 mayreceive trained model objects 602 generated at the wearability modelbuilding module 218, and prediction data 604 generated at the predictiondata processing module 222. The prediction data 604 may comprise dataattributes (e.g., UUID-SKU pairs) linked with other attribute levelanalytics, as described in detail above with respect to FIGS. 1 and 2.The predictive metrics generating module 224 may then predict one ormore predictive wearability metrics 608 indicative of propensity towear, by executing the received one or more trained model objects 602with the prediction data 604 (Step 606).

FIG. 7 depicts an exemplary method 700 for generating predictivewearability metrics using trained model objects, according to one ormore alternative embodiments. The predictive metrics generating module224 may acquire an existing set of prediction data 702, which weregenerated at the prediction data processing module 222. The predictiondata 604 may comprise data attributes (e.g., UUID-SKU pairs) linked withother attribute level analytics, as described in detail above withrespect to FIGS. 1 and 2. Subsequently, the predictive metricsgenerating module 224 download a new set of prediction data 706, basedon, for example, an automatic or manual prompt to download another setof prediction data (Step 704). The new set of prediction data 706 maythen augment, replace, or be otherwise combined with the existing set ofprediction data 702, to form the prediction data. The predictive metricsgenerating module 224 may then predict one or more predictivewearability metrics 712 indicative of propensity to wear, by receivingtrained model objects 708 (e.g., from the wearability model buildingmodule 218) and executing the received one or more trained model objects708 with the prediction data, and generate the predictive wearabilitymetrics 712 (Step 710).

FIG. 8 depicts a flowchart of an exemplary method for executing neuralnetwork training for dynamically predicting apparel wearability,according to one or more embodiments. In the exemplary method 800, oneor more computer processors may generate a training data set comprisingone or more historical data attributes of previously shipped apparel,each of the historical data attributes being linked to a unique useridentifier and a unique apparel identifier (Step 805). The one or moreprocessors may train a neural network based on the training data set toconfigure one or more trained models to output a metric for any pair ofa unique user identifier and a unique apparel identifier. (Step 810).The one or more processors may store the one or more trained models asone or more trained model objects. (Step 815). The one or moreprocessors may collect prediction data comprising at least oneprediction pair including a unique user identifier and a unique apparelidentifier, each prediction pair corresponding to a closeted garment ora returned garment (Step 820). The one or more processors may predictone or more predictive wearability metrics indicative of propensity towear, by executing the stored one or more trained model objects with theprediction data, wherein the one or more predictive wearability metricsare one or more metrics output by the executed one or more trained modelobjects (Step 825). The one or more processors may dynamically generateone or more match pairs, each match pair including a unique useridentifier and a unique apparel identifier (Step 830). The one or moreprocessors may determine a match wearability metric for each of the oneor more match pairs based on the predicted one or more wearabilitymetrics. (Step 835).

Although FIGS. 3-8 show example blocks of processes 300-800, in someimplementations, processes 300-800 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIGS. 3-8. Additionally, or alternatively, two or more ofthe blocks of processes 300-800 may be performed in parallel.

FIG. 9 depicts a high-level functional block diagram of an exemplarycomputer device or system, in which embodiments of the presentdisclosure, or portions thereof, may be implemented, e.g., ascomputer-readable code. In some implementations, any combination ofcomponents depicted in the environment 100 of FIG. 1 or in theenvironment 200 of FIG. 2 may correspond to device 900. Additionally,each of the exemplary computer servers, devices, databases, userinterfaces, and methods described above with respect to FIGS. 1-8 can beimplemented in device 900 using hardware, software, firmware, tangiblecomputer readable media having instructions stored thereon, or acombination thereof and may be implemented in one or more computersystems or other processing systems. Hardware, software, or anycombination of such may implement each of the exemplary systems, userinterfaces, and methods described above with respect to FIGS. 1-8.

If programmable logic is used, such logic may be executed on acommercially available processing platform or a special purpose device.One of ordinary skill in the art may appreciate that embodiments of thedisclosed subject matter can be practiced with various computer systemconfigurations, including multi-core multiprocessor systems,minicomputers, mainframe computers, computers linked or clustered withdistributed functions, as well as pervasive or miniature computers thatmay be embedded into virtually any device.

For instance, at least one processor device and a memory may be used toimplement the above-described embodiments. A processor device may be asingle processor or a plurality of processors, or combinations thereof.Processor devices may have one or more processor “cores.”

Various embodiments of the present disclosure, as described above in theexamples of FIGS. 1-8, may be implemented using device 900. Afterreading this description, it will become apparent to a person skilled inthe relevant art how to implement embodiments of the present disclosureusing other computer systems and/or computer architectures. Althoughoperations may be described as a sequential process, some of theoperations may in fact be performed in parallel, concurrently, and/or ina distributed environment, and with program code stored locally orremotely for access by single or multi-processor machines. In addition,in some embodiments the order of operations may be rearranged withoutdeparting from the spirit of the disclosed subject matter.

As shown in FIG. 9, device 900 may include a central processing unit(CPU) 920. CPU 920 may be any type of processor device including, forexample, any type of special purpose or a general-purpose microprocessordevice. As will be appreciated by persons skilled in the relevant art,CPU 920 also may be a single processor in a multi-core/multiprocessorsystem, such system operating alone, or in a cluster of computingdevices operating in a cluster or server farm. CPU 920 may be connectedto a data communication infrastructure 910, for example, a bus, messagequeue, network, or multi-core message-passing scheme.

Device 900 also may include a main memory 940, for example, randomaccess memory (RAM), and also may include a secondary memory 930.Secondary memory 930, e.g., a read-only memory (ROM), may be, forexample, a hard disk drive or a removable storage drive. Such aremovable storage drive may comprise, for example, a floppy disk drive,a magnetic tape drive, an optical disk drive, a flash memory, or thelike. The removable storage drive in this example reads from and/orwrites to a removable storage unit in a well-known manner. The removablestorage unit may comprise a floppy disk, magnetic tape, optical disk,etc., which is read by and written to by the removable storage drive. Aswill be appreciated by persons skilled in the relevant art, such aremovable storage unit generally includes a computer usable storagemedium having stored therein computer software and/or data.

In alternative implementations, secondary memory 930 may include othersimilar means for allowing computer programs or other instructions to beloaded into device 900. Examples of such means may include a programcartridge and cartridge interface (such as that found in video gamedevices), a removable memory chip (such as an EPROM, or PROM) andassociated socket, and other removable storage units and interfaces,which allow software and data to be transferred from a removable storageunit to device 900.

Device 900 also may include a communications interface (“COM”) 960.Communications interface 960 allows software and data to be transferredbetween device 900 and external devices. Communications interface 960may include a modem, a network interface (such as an Ethernet card), acommunications port, a PCMCIA slot and card, or the like. Software anddata transferred via communications interface 960 may be in the form ofsignals, which may be electronic, electromagnetic, optical, or othersignals capable of being received by communications interface 960. Thesesignals may be provided to communications interface 960 via acommunications path of device 900, which may be implemented using, forexample, wire or cable, fiber optics, a phone line, a cellular phonelink, an RF link or other communications channels.

The hardware elements, operating systems and programming languages ofsuch equipment are conventional in nature, and it is presumed that thoseskilled in the art are adequately familiar therewith. Device 900 alsomay include input and output ports 950 to connect with input and outputdevices such as keyboards, mice, touchscreens, monitors, displays, etc.Of course, the various server functions may be implemented in adistributed fashion on a number of similar platforms, to distribute theprocessing load. Alternatively, the servers may be implemented byappropriate programming of one computer hardware platform.

The systems, apparatuses, devices, and methods disclosed herein aredescribed in detail by way of examples and with reference to thefigures. The examples discussed herein are examples only and areprovided to assist in the explanation of the apparatuses, devices,systems, and methods described herein. None of the features orcomponents shown in the drawings or discussed below should be taken asmandatory for any specific implementation of any of these theapparatuses, devices, systems, or methods unless specifically designatedas mandatory. For ease of reading and clarity, certain components,modules, or methods may be described solely in connection with aspecific figure. In this disclosure, any identification of specifictechniques, arrangements, etc. are either related to a specific examplepresented or are merely a general description of such a technique,arrangement, etc. Identifications of specific details or examples arenot intended to be, and should not be, construed as mandatory orlimiting unless specifically designated as such. Any failure tospecifically describe a combination or sub-combination of componentsshould not be understood as an indication that any combination orsub-combination is not possible. It will be appreciated thatmodifications to disclosed and described examples, arrangements,configurations, components, elements, apparatuses, devices, systems,methods, etc. can be made and may be desired for a specific application.Also, for any methods described, regardless of whether the method isdescribed in conjunction with a flow diagram, it should be understoodthat unless otherwise specified or required by context, any explicit orimplicit ordering of steps performed in the execution of a method doesnot imply that those steps must be performed in the order presented butinstead may be performed in a different order or in parallel.

Throughout this disclosure, references to components or modulesgenerally refer to items that logically can be grouped together toperform a function or group of related functions. Like referencenumerals are generally intended to refer to the same or similarcomponents. Components and modules can be implemented in software,hardware, or a combination of software and hardware. The term “software”is used expansively to include not only executable code, for examplemachine-executable or machine-interpretable instructions, but also datastructures, data stores and computing instructions stored in anysuitable electronic format, including firmware, and embedded software.The terms “information” and “data” are used expansively and includes awide variety of electronic information, including executable code;content such as text, video data, and audio data, among others; andvarious codes or flags. The terms “information,” “data,” and “content”are sometimes used interchangeably when permitted by context.

It is intended that the specification and examples be considered asexemplary only, with a true scope and spirit of the disclosure beingindicated by the following claims.

1-20. (canceled)
 21. A computer-implemented method for executing machinelearning training for dynamically predicting product usage in anelectronics transactions platform, the method comprising: generating, byone or more processors, a training data set comprising one or morehistorical data attributes of previously used products, each of thehistorical data attributes being linked to a pair of a unique useridentifier and a unique product identifier used in the electronictransactions platform to form feature vectors for each pair of a uniqueuser identifier and a unique product identifier; training, by the one ormore processors, a machine learning model based on the training data setto configure one or more trained models to output a metric for any pairof a unique user identifier and a unique product identifier used in theelectronic transactions platform; storing, by the one or moreprocessors, the one or more trained models as one or more trained modelobjects at a database of the electronic transactions platform;collecting, by the one or more processors, prediction data comprising atleast one prediction pair including a unique user identifier and aunique product identifier used in the electronic transactions platform,each prediction pair corresponding to product saved for a futuretransaction, purchased, or returned through the electronic transactionsplatform; executing, by the one or more processors, the stored one ormore trained model objects with the prediction data to determine one ormore predictive usage metrics indicative of a propensity of a user touse product saved for a future transaction, purchased, or returned;periodically storing the one or more predictive usage metrics at ametrics database of the electronic transactions platform, whereinstoring the one or more predictive usage metrics includes storing afirst predictive usage metric associated with a first prediction pair,the first prediction pair including a first unique user identifier and afirst unique product identifier, the first predictive usage metricindicating a propensity of a user associated with the first unique useridentifier to use product associated with the first unique productidentifier; dynamically generating, by the one or more processors, oneor more match pairs, each match pair including a unique user identifierand a unique product identifier used in the electronic transactionsplatform; and periodically determining, by the one or more processors, amatch usage metric for each of the one or more match pairs based on thestored one or more predictive usage metrics, wherein determining thematch usage metric for each of the one or more match pairs includes:determining a first match pair including the first unique useridentifier and the first unique product identifier, retrieving thestored first predictive usage metric associated with the first uniqueuser identifier and the first unique product identifier, and storing theretrieved first predictive usage metric as a first match usage metricfor the first match pair, the first match usage metric indicating thepropensity of the user associated with the first unique user identifierto use product associated with the first unique product identifier. 22.The method of claim 21, wherein the generating the training data setfurther comprises determining one or more distributions of fit ratingscorresponding to a unique product identifier.
 23. The method of claim21, wherein the storing the one or more predictive usage metricsincludes limiting the storing the one or more predictive usage metricsbased on preset conditions.
 24. The method of claim 21, wherein themetrics database is a database configured to index, retrieve, and searcha plurality of data files comprising the one or more predictive usagemetrics.
 25. The method of claim 23, wherein the storing the one or morepredictive usage metrics includes cleaning the stored one or morepredictive usage metrics based on additional preset conditions.
 26. Themethod of claim 21, wherein the determining the match usage metric foreach of the one or more match pairs further comprises retrieving apredictive usage metric among the one or more predictive usage metricsstored at the metrics database.
 27. The method of claim 21, wherein thedynamically generating the one or more match pairs is performed inresponse to receiving one or more replenishment identifiers.
 28. Acomputer system for executing machine learning training for dynamicallypredicting product usage in an electronics transactions platform, thecomputer system comprising: a memory having processor-readableinstructions stored therein; and at least one processor configured toaccess the memory and execute the processor-readable instructions, whichwhen executed by the at least one processor configures the at least oneprocessor to perform a plurality of functions, including functions for:generating a training data set comprising one or more historical dataattributes of previously used products, each of the historical dataattributes being linked to a pair of a unique user identifier and aunique product identifier used in the electronics transactions platformto form feature vectors for each pair of a unique user identifier and aunique product identifier; training a machine learning model based onthe training data set to configure one or more trained models to outputa metric for any pair of a unique user identifier and a unique productidentifier used in the electronics transactions platform; storing theone or more trained models as one or more trained model objects at adatabase of the electronics transactions platform; collecting predictiondata comprising at least one prediction pair including a unique useridentifier and a unique product identifier used in the electronictransactions platform, each prediction pair corresponding to productsaved for a future transaction, purchased, or returned through theelectronic transactions platform; executing the stored one or moretrained model objects with the prediction data to determine one or morepredictive usage metrics indicative of a propensity of a user to useproduct saved for a future transaction, purchased, or returned;periodically storing the one or more predictive usage metrics at ametrics database of the electronic transactions platform, whereinstoring the one or more predictive usage metrics includes storing afirst predictive usage metric associated with a first prediction pair,the first prediction pair including a first unique user identifier and afirst unique product identifier, the first predictive usage metricindicating a propensity of a user associated with the first unique useridentifier to use product associated with the first unique productidentifier; dynamically generating one or more match pairs, each matchpair including a unique user identifier and a unique product identifierused in the electronic transactions platform; and periodicallydetermining a match usage metric for each of the one or more match pairsbased on the stored one or more usage metrics, wherein determining thematch usage metric for each of the one or more match pairs includes:determining a first match pair including the first unique useridentifier and the first unique product identifier, retrieving thestored first predictive usage metric associated with the first uniqueuser identifier and the first unique product identifier, and storing theretrieved first predictive usage metric as a first match usage metricfor the first match pair, the first match usage metric indicating thepropensity of the user associated with the first unique user identifierto use product associated with the first unique product identifier. 29.The system of claim 28, wherein the generating the training data setfurther comprises determining one or more distributions of fit ratingscorresponding to a unique product identifier.
 30. The system of claim28, wherein the storing the one or more predictive usage metricsincludes limiting the storing the one or more predictive usage metricsbased on preset conditions.
 31. The system of claim 28, wherein themetrics database is a database configured to index, retrieve, and searcha plurality of data files comprising the one or more predictive usagemetrics.
 32. The system of claim 30, wherein the storing the one or morepredictive usage metrics includes cleaning the stored one or morepredictive usage metrics based on additional preset conditions.
 33. Thesystem of claim 28, wherein the determining the match usage metric foreach of the one or more match pairs further comprises retrieving apredictive usage metric among the one or more predictive usage metricsstored at the metrics database.
 34. The system of claim 28, wherein thedynamically generating the one or more match pairs is performed inresponse to receiving one or more replenishment identifiers.
 35. Anon-transitory computer-readable medium containing instructions forexecuting machine learning training for dynamically predicting productusage in an electronics transactions platform, comprising: generating atraining data set comprising one or more historical data attributes ofpreviously used products, each of the historical data attributes beinglinked to a pair of a unique user identifier and a unique productidentifier used in the electronic transactions platform to form featurevectors for each pair of a unique user identifier and a unique productidentifier; training a machine learning model based on the training dataset to configure one or more trained models to output a metric for anypair of a unique user identifier and a unique product identifier used inthe electronic transactions platform; storing the one or more trainedmodels as one or more trained model objects at a database of theelectronic transactions platform; collecting prediction data comprisingat least one prediction pair including a unique user identifier and aunique product identifier used in the electronic transactions platform,each prediction pair corresponding to product saved for a futuretransaction, purchased, or returned through the electronic transactionsplatform; executing the stored one or more trained model objects withthe prediction data to determine one or more predictive usage metricsindicative of a propensity of a user to use product saved for a futuretransaction, purchased, or returned; periodically storing the one ormore predictive usage metrics at a metrics database of the electronictransactions platform, wherein storing the one or more predictive usagemetrics includes storing a first predictive usage metric associated witha first prediction pair, the first prediction pair including a firstunique user identifier and a first unique product identifier, the firstpredictive usage metric indicating a propensity of a user associatedwith the first unique user identifier to use product associated with thefirst unique product identifier; dynamically generating one or morematch pairs, each match pair including a unique user identifier and aunique product identifier used in the electronic transactions platform;and periodically determining a match usage metric for each of the one ormore match pairs based on the stored one or more usage metrics, whereindetermining the match usage metric for each of the one or more matchpairs includes: determining a first match pair including the firstunique user identifier and the first unique product identifier,retrieving the stored first predictive usage metric associated with thefirst unique user identifier and the first unique product identifier,and storing the retrieved first predictive usage metric as a first matchusage metric for the first match pair, the first match usage metricindicating the propensity of the user associated with the first uniqueuser identifier to use product associated with the first unique productidentifier.
 36. The non-transitory computer-readable medium of claim 35,wherein the generating the training data set further comprisesdetermining one or more distributions of fit ratings corresponding to aunique product identifier.
 37. The non-transitory computer-readablemedium of claim 35, wherein determining the match usage metric for eachof the one or more match pairs based on the predicted one or morepredictive usage metrics comprises: retrieving the stored one or morepredictive usage metrics from the metrics database.
 38. Thenon-transitory computer-readable medium of claim 35, wherein the metricsdatabase is a database configured to index, retrieve, and search aplurality of data files comprising the one or more predictive usagemetrics.
 39. The non-transitory computer-readable medium of claim 35,wherein the storing the one or more predictive usage metrics includeslimiting the storing the one or more predictive usage metrics based onpreset conditions.
 40. The non-transitory computer-readable medium ofclaim 35, wherein the dynamically generating the one or more match pairsis performed in response to receiving one or more replenishmentidentifiers.